Native desktop windows - #5556

Adds Component.getTopLevelContainer(), the resolution path that replaces
getComponentForm() in code which has to keep working inside a desktop Window.
getComponentForm() is untouched and keeps its meaning: it returns the enclosing
Form, and null for a component hosted in a Window, because a Window is not a
Form.

The internals that Component, Container and Toolbar need in order to drive a top
level -- the internal animation registry, focus, the revalidate queue, the drag
and press state -- are declared package private on Container rather than on an
interface. Every method of a Java interface is implicitly public, so an interface
would have silently widened Form's public API; Container is the nearest common
supertype of Form and Window, so the calls still dispatch virtually with no
instanceof. The defaults are inert and Form overrides the ones that mean
something to it.

Also adds com.codename1.impl.WindowManager, the single facade carrying the whole
native windowing contract, reached through one new
CodenameOneImplementation.getWindowManager() that returns null by default. This
follows getHealth()/getBluetooth()/getCarBridge(), and keeps several dozen
methods out of an already very large class. The null return is itself the
capability query, so no separate supported flag can drift out of step with it.
Only operations every windowing system provides are abstract; the rest have inert
defaults so a later addition cannot break an existing port.

No behaviour change: no port implements a window manager yet.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Migrates the load-bearing call sites in Component and Container off
getComponentForm() and onto getTopLevelContainer(), so they keep working when
the root of the hierarchy is a Window instead of a Form.

The sites were picked by reading, not by pattern. Two groups:

Sites that dereferenced the Form with no null check, and so would have thrown
rather than degraded: growShrink and its BGPainter animate loop, the material
pull to refresh release, the deinitialize path that unhooks the refresh drag
listener, chooseScrollXOrY, moveScrollTowards, and the drop handler that
animates the hierarchy. Several of these could already NPE today for a component
detached mid animation, so they are now guarded as well as migrated.

Sites that were guarded and would therefore have gone quiet -- the worse failure,
because each one silently removes a whole feature: all pointer dragging, kinetic
and smooth scrolling, drag and drop, focus, the animation manager behind every
animateLayout, animated backgrounds, the revalidate-on-style-change gate, and
revalidateInternal, which is the root of the layout system.

Adds four more package private hooks to Container that these sites need --
getFocused, isRevalidateFromRoot and the directional focus finders -- following
the pattern established for the rest: inert defaults on Container, overridden by
the top level.

Left alone deliberately: fireFocusGained and fireFocusLost reach for
getMenuBar(), which a Window has no equivalent of, so the existing null guard
already yields the right behaviour there.

All 4790 core unit tests pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Groups the four fields that describe "the thing being painted" -- the dirty
queue, its swap buffer, the fill count and the Graphics -- into a PaintSurface.
The application's main surface becomes one instance of it, and a later commit
gives every native window another.

paintDirty() keeps its signature and behaviour and now delegates to a
surface-parameterized routine, with paintDirtyWindow() entering the same routine
for a window. Having one copy matters: that method carries the clip and
paintable-bounds handling from issue #5273, and a per-surface copy would be free
to drift.

The flush-region hint is routed per surface. Its window form is inert by default
rather than delegating to the main-surface version, so an immediate mode port
that has not opted in cannot clamp a window's clip against the main window's
state.

repaint(), cancelRepaint() and hasPendingPaints() keep their signatures, so the
JavaSE and Android overrides that call super still compile and behave. cancelRepaint
now sweeps every surface, since its callers have no window context.

No behaviour change: nothing creates a window surface yet.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Extracts the layer lookup and z-index insertion out of Form into
TopLevelSupport, so Window can reuse it instead of carrying a second copy.

The logic is moved verbatim, including the getChildrenAsList(true) reads: the
comment there is load bearing, since iterating the container directly does not
find components while an animation is in progress and the method would then add
a duplicate layer.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Window is the desktop counterpart of Form: a second native operating system
window with its own component hierarchy, focus owner, animations, revalidate
queue and dirty region. The main surface stays a Form and is untouched.

Desktop is the public API parallel to Display. Display keeps answering "how big
is the application's main surface", which is the only question a phone has;
Desktop answers "what screens exist and what windows are open". It owns the
window registry and hands out Monitor snapshots, and every one of its methods
degrades safely where there is no windowing system -- an empty window array, a
single monitor describing the main display -- so only constructing a Window
throws.

Monitor carries per-monitor geometry, work area, density and backing scale, and
a Window reports the density and scale of the monitor it is currently on rather
than the global one, which is what makes a mixed-DPI desktop render correctly.

Event routing packs the window id into the high bits of the event type word.
Window 0 is the main surface, and for it the packed word is numerically
identical to what it always was, so the wire format, drag coalescing and the
stack swap are all untouched. The id is an int chosen by the framework and
echoed back by the port, so the off-EDT input path needs no map and no lock.
Key repeat and long press now return to the top level the press came from.

Fixes a latent infinite EDT spin this makes reachable: handleEvent returned
without advancing the offset when it had no form to dispatch to, while the
caller loops while (offset < end). It was unreachable only because the public
entry points all guard on a non-null current form. skipEvent now drains the
packet so the rest of the batch -- which may contain main form events -- still
dispatches.

Fixes two adjacent bugs the same code path forced into the open: a key or
pointer release aimed at a different form than the press left its payload in the
stack, where it was then read as the next event type; and the multi-touch
release passed the x array as both coordinates.

Modality blocks input in core rather than in the ports, so a modal window
behaves identically everywhere whether or not the platform implements its own;
ports still set the native flag for correct focus and taskbar behaviour.
showModal parks the caller through invokeAndBlock exactly as a modal Dialog
does, so every other window keeps painting.

All 4790 core unit tests pass. Two of them reach into the paint queue by
reflection and were updated for its move onto PaintSurface.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Removes the two assumptions in the JavaSE port that there is exactly one canvas,
which is what stands between it and a second rendered window.

getGraphics(Object) fell through to canvas.getGraphics2D() for any screen
graphics, so a secondary window would have drawn into the primary window's
buffer. NativeScreenGraphics now records the canvas it belongs to and resolves
through that.

isScreenGraphics(Graphics2D) was literally an identity comparison against the
primary canvas's buffer. It is now a membership test over the registered screen
buffers. This matters because drawNativePeerImpl uses it to decide whether to
undo the zoom scale, so answering wrongly for a second window would mis-scale
its peer components.

The registry is maintained at the only three places C.g2dInstance is written --
created in getGraphics2D, discarded in createBufferedImage and in the size
change reset -- so it cannot drift.

Behaviour with a single window is unchanged: the primary canvas is still the
owner of its own graphics, and the membership test still answers true for
exactly the buffer the identity comparison used to.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The first real port implementation, and the one that decides whether the design
holds. Each Codename One Window becomes a JFrame containing its own instance of
the port's existing C canvas, so a second window inherits the whole buffered
blit machine -- including the blitCounter aliasing fast path, which is already
per-instance state -- with none of it duplicated.

Input is tagged at the source: C carries the window id it renders and its
listeners dispatch through the window-aware entry points, so an event reaches
the right hierarchy without a lookup on the AWT thread. Window id zero routes to
the main surface, so the primary canvas keeps its exact previous behaviour.

Monitors come from GraphicsEnvironment, with the work area taken from the screen
insets so a window centres or maximises without landing under the task bar or
dock, and the backing scale from each GraphicsConfiguration's default transform
rather than one global retina scale. A window that is dragged onto a display
with a different scale raises a monitor-changed event, which is what lets the
framework re-lay it out instead of leaving it blurry.

Multi-window reports unsupported while a phone skin is loaded, reusing the
predicate isFullScreenSupported already applies: a skin simulates one device
screen with its own coordinates and zoom, and a real operating system window
inside that simulation is incoherent. Headless likewise.

Also qualifies java.awt.Window in SourceChangeWatcher, which wildcard-imports
both java.awt and com.codename1.ui and so became ambiguous the moment
com.codename1.ui.Window existed. A repo-wide scan found no other collisions.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Adds TestWindowManager, a window manager with no operating system behind it, and
wires it into TestCodenameOneImplementation as an opt-in. It defaults to absent,
so the unsupported platform every mobile port reports is also the default a test
sees, and the throwing path is exercised without arranging anything.

Its monitor table is scriptable, which is what makes per-monitor DPI testable at
all: DesktopMonitorTest describes a 2x laptop panel with a dock reserved at the
bottom next to a conventional external display, then asserts that a window picks
up the scale and density of whichever one it sits on and that moving between them
marks its preferred sizes stale. Getting that wrong is what produces a blurry or
mis-sized window, and it would otherwise need a second physical display to catch.

WindowTest covers the rest of the contract: constructing a Window on an
unsupported platform throws rather than degrading, Desktop still answers safely
there, show creates exactly one native window, dispose releases it and is
idempotent, title and bounds reach the native window, close honours the close
operation and can be vetoed, chrome and modality reach the peer, and each window
gets its own id since events are routed by it.

Two assertions are the load-bearing ones for the chosen design: a component in a
Window resolves that Window through getTopLevelContainer(), and getComponentForm()
returns null for it -- while a component in a Form still resolves both.

4808 core unit tests pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…ates

SpotBugs is a zero-findings gate and this change tripped ten. Fixing them
properly rather than excluding them turned up a real gap.

Five were unused fields on Window -- the press coordinates, the press token and
the dragged component. They were unused because Window had no pointer dispatch
at all: Container does no hit testing of its own, Form does that work itself, so
without it a press inside a window never reached the component under it. Window
now performs the same walk Form does, minus the title area and menu bar special
cases it has no equivalent of, and implements the Container hooks that expose the
press state -- which is what the migrated drag and scroll code in Component reads.

One was a naked notify in dispose(). The flag showModal parks on is now published
under the very monitor the waiter is blocked on, with a separate flag guarding
re-entry, so the wake is tied to the state change rather than being incidental.

Four were anonymous Runnables in Display retaining their enclosing instance.
They are now one named static WindowCallback.

SpotBugs, PMD and Checkstyle are clean over core-unittests; 4808 tests pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Both were parented to the primary canvas unconditionally, so a BrowserComponent
or a text field inside a desktop Window would have appeared on the main window
instead of the one containing it.

Peer.addNativeCnt now resolves its frame through the owning window at attach
time rather than at construction: a peer is created before it is added to a
hierarchy, so its window is not knowable when the Peer object is built.

editString attaches the Swing editor to the owning window's canvas, and
stopTextEditing removes it from whichever canvas it actually landed on rather
than assuming the primary one.

Both resolve through Display.getWindowPeerForComponent, which walks the
component's top level -- so a component on the main form still gets exactly the
previous behaviour.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Adds desktop windows to the native Windows port. Each Codename One Window is a
slot in a new native table with its own HWND, ID2D1HwndRenderTarget and
CN1Graphics.

The main window is deliberately left out of that table. It stays in cn1Win with
its existing HWND, render target and graphics untouched, so the single-window
path -- which every existing app and every screenshot baseline exercises --
cannot change behaviour. Secondary windows also get their own window procedure
rather than sharing the main one, which is full of main-window-only cases.

Window identity in that procedure comes from GWLP_USERDATA set in WM_NCCREATE:
O(1) and lock free, which matters because it runs on the pump thread while the
EDT is drawing. Events carry the framework's window id, which the native side
stores at creation and echoes back, so routing needs no lookup.

Creation and destruction marshal to the pump thread through a new
WM_CN1_DESKTOPWINDOW, following the blocking SendMessageW pattern the native edit
control and file dialog already use -- a window must be created on the thread
that owns the message loop. Everything else is legal cross-thread and runs
directly. The message loop itself needs no change: GetMessageW already pumps
every window owned by the thread.

Two things carried over deliberately from the main window because getting them
wrong is subtle: D2D1_PRESENT_OPTIONS_RETAIN_CONTENTS, since Codename One
repaints only the dirty region and relies on the rest surviving the present; and
recording a resize for the drawing thread to apply between frames rather than
resizing the render target from the pump thread, which presents black.

WM_DPICHANGED honours the rectangle Windows suggests and reports the monitor
change, which is what keeps a drag between mixed-DPI displays from leaving the
window the wrong physical size. Monitors come from EnumDisplayMonitors with the
work area from MONITORINFO, and per-monitor DPI from GetDpiForMonitor resolved
dynamically since shcore.dll only exists from Windows 8.1.

WM_DESTROY on a secondary window deliberately does not PostQuitMessage: closing
a tool window must not exit the application.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Adds desktop windows to the native Linux port. Each Codename One Window is a slot
in a new native table carrying its own GtkWindow, GtkOverlay, GtkDrawingArea,
GtkFixed peer layer and cairo back buffer. The main window keeps its own file
statics in cn1_linux_window.c and is not part of that table, so the existing
single-window path is unchanged.

Routing is essentially free here, which is the nice part of GTK: every signal
handler already takes a gpointer closure, so passing the window struct as the
closure data makes each handler window-scoped with no lookup and no shared state.
gtk_main_iteration already services every window in the process, so the loop
needs no change either.

Events carry the framework's window id, stored at creation and echoed back. The
delete-event handler returns TRUE so GTK does not destroy the window: Codename
One decides, because an application may veto the close from a listener.

The window's back buffer sets isWindowTarget, which turns on the #5273 clip
clamp -- a clip set while a component paints is confined to the region about to
be flushed, so an oversized fill cannot leave stale pixels on the persistent
cairo surface.

GTK is not thread safe, so every entry point marshals to the GTK main thread
through cn1LinuxRunOnMainAndWait, which the port already uses for exactly this.

Monitors come from GdkDisplay, with the work area from gdk_monitor_get_workarea.
Scale reports GTK's integer scale factor, since that is what actually governs how
the toolkit renders, while dots per inch is derived separately from the monitor's
reported millimetre size -- the integer factor is far too coarse to describe a
display's real resolution.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Adds desktop windows to the Mac Catalyst slice. A Codename One Window becomes a
UIWindowScene, with the whole implementation inside #if TARGET_OS_MACCATALYST so
the object file an iPhone or iPad build produces is empty and the plain iOS
binary is unchanged.

Unlike the other desktop ports, the window's content is rendered into a mutable
image and the finished raster is assigned to the scene view's layer, rather than
the window owning a second Metal surface. That is a deliberate trade: the render
path caches its device, pipeline state and glyph atlas against the single
rendering view, and making those per-scene is a large refactor of the hottest
code in the product, without ARC. The scene still owns a real UIKit view
hierarchy, so native peers and native text editing work normally inside a window
-- only the drawing arrives as a bitmap.

Multi-window is opt-in through a new macNative.multiWindow build hint. That is
not caution for its own sake: the existing comment in IPhoneBuilder records that
turning UIApplicationSupportsMultipleScenes on changed Catalyst windowing and
crashed the screenshot suite with a 26 GB signal loop. The hint now gates both
that Info.plist key and IOSImplementation.getWindowManager(), so the key and the
API that requires it are switched by the same flag and cannot disagree.

Scene arrival is asynchronous, so a created window claims the next scene the
delegate receives; the delegate hands it over before installing the main root
view controller, and only the application's own scene falls through to that.
Teardown releases the scene, window, controller, view and title on the main
queue after UIKit has finished with them, since this port has no ARC.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The part of the test story that actually demonstrates windowing. A picture of a
window proves nothing; these re-run representative UI INSIDE a real operating
system window and compare that window's own capture against its own baseline.

WindowHostTest hosts content in a Window at three sizes -- 400x300, 900x700 and a
deliberately non-square 1000x400 -- and captures through Window.capture() rather
than Display.screenshot, because the ordinary path can only see the application's
main framebuffer and a second window simply is not in it. The three sizes are the
point: a window still measuring itself against the main display would produce
three near-identical goldens.

The cases were chosen for what fails silently rather than for coverage count.
Layout proves sizing and theming resolve against the window. Scroll proves the
scroll path, which goes quiet rather than throwing if a component cannot resolve
its top level. Graphics exercises the port's pipeline on a non-primary render
target with shapes that deliberately reach the edges, where a wrong clip clamp
leaves stale pixels. Editing covers native text input, which used to attach the
platform editor to the main window's canvas unconditionally. Overlay covers the
layered pane that Sheet, InteractionDialog and ToastBar attach to. Modal captures
the BACKGROUND window while a modal is up, which is the state that would be blank
if the nested event loop had stopped servicing it.

MultiWindowApiTest is the behavioural half: no screenshot, runs everywhere, and
asserts against what the port reports rather than pixels. Where there is no
windowing system it asserts the opposite -- that the capability query says so and
that constructing a Window throws rather than degrading.

The suite skips without emitting a golden where windows are unsupported, so
mobile baselines never contain a picture of something the platform cannot do. The
new tests are recorded as not-run in every stored port report, which is honest:
CI has not executed them on those targets yet.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Adds a Desktop Windows chapter next to Desktop Integration, covering the whole
feature: where windows exist and where they throw, the Form/Window relationship
through TopLevelContainer, lifecycle and close vetoes, chrome and the two
coordinate systems, modality, monitors and per-monitor DPI, events, peers and
native editing, and the Mac Catalyst opt-in.

Two things are called out rather than buried, because they are what will
actually catch someone out. getComponentForm() returns null inside a Window, and
the failure mode is silence rather than an exception, since most code guards on
null and quietly does nothing -- so a component that will not scroll or focus in
a window has a named cause. And Catalyst multi-window needs the
macNative.multiWindow build hint, because a second window is a second scene and
that requires a process-wide Info.plist key.

Vale reports zero issues at suggestion level, LanguageTool zero matches across
the guide, and the paragraph capitalization check passes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Adds a port-level test for the riskiest edit in this work, which had no coverage
before and sits in the paint path where a regression shows up as wrong pixels
rather than an exception.

Two canvases must resolve to two distinct screen buffers -- sharing one is
exactly what would make a second window draw into the first window's pixels. And
isScreenGraphics has to answer true for a secondary window's buffer as well as
the primary one, but still false for a mutable image: drawNativePeerImpl uses
that answer to decide whether to undo the zoom scale, so a wrong answer
mis-scales a window's peer components.

222 JavaSE port tests pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Compiling CN1MacWindows.m against the actual Mac Catalyst SDK -- which the
earlier commit never did -- turned up three defects that would have shipped.

Scene-to-window matching was a race. Creation returns a slot immediately and
requests the scene asynchronously, and the arriving scene was handed to the
first unattached slot. Two windows opened in quick succession could therefore
swap identities. Scenes are delivered in request order, so the pending slots are
now a FIFO, enqueued on the same main-thread turn as the request; a window
destroyed before its scene arrives leaves the queue.

The presented frame was a use-after-free waiting to happen. flushGraphics
allocates a local Java int[], and the native side wrapped that pointer in a
CGBitmapContext, then used the resulting image on a later main-queue turn -- by
which time the array is garbage and the collector may have reclaimed or moved
it. The pixels are now copied, and handed to a CGDataProvider with a release
callback rather than a bitmap context: CGBitmapContextCreateImage is
copy-on-write, so it is not defined when the backing buffer becomes free to
release, whereas the provider makes that lifetime explicit.

The alpha format was wrong. getRGB returns straight ARGB and the image declared
kCGImageAlphaPremultipliedFirst, which would darken every pixel that is not
fully opaque. A window's content is opaque, so it now skips the alpha channel.

Also uses slotForScene, which was dead code, to reject a scene that was already
adopted.

Verified by compiling both CN1MacWindows.m and CodenameOne_GLSceneDelegate.m for
arm64-apple-ios-macabi against the real SDK: clean with -Wall. The same file
built for plain iOS exports zero CN1MacWindow symbols, confirming the whole
implementation compiles out and the iOS binary is unchanged.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Compiling the native sources -- which the port commits never did -- turned up
three defects, one of them serious.

WM_CN1_DESKTOPWINDOW was defined as WM_APP + 24, which WM_CN1_WIDGET already
uses. Widget ops and desktop-window ops would have been delivered to each
other's handlers, both of them casting the same LPARAM to a different struct.
Moved to WM_APP + 25; the duplicate is now checked for rather than assumed
absent.

The two COM release calls in the Windows window layer did not resolve. This port
compiles its Direct2D translation units as C++ and resolves COBJMACROS-style
call sites through an explicit shim in cn1_windows_comc.h, which defines only the
methods the port actually uses -- and it had no Release entry for either the
HWND render target or the solid colour brush. Added both, in the shim's existing
style, rather than reaching around it.

On Linux, the GtkWidget-typed accessors were declared in cn1_linux.h. That header
is included by translation units that have no GTK on their include path, and
declaring a GtkWidget* there breaks them. Moved to cn1_linux_gfx.h, which is the
header that includes gtk and where the equivalent existing declarations already
live.

Verified with the real toolchains available here: cn1_linux_desktopwindow.c is
clean under -Wall against GTK 3, and every Windows translation unit including the
new one now reports zero errors of its own. The remaining diagnostics in both
ports reproduce identically on master and come from compiling Linux and Windows
sources on a Mac.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…ault

Findings from actually building and running the Catalyst app on a Mac, which no
earlier commit had done.

MacWindowManager never implemented capture(), so it inherited the base class's
null. Every windowed screenshot test failed with "Window capture returned null".
On this platform the window's content is already rendered into a mutable image,
so a capture is that raster.

The screenshot harness waited a fixed 1.2s on a UITimer bound to the current
form. Catalyst creates its window asynchronously -- it asks the system to
activate a scene and is handed one back later -- so a fixed delay is both too
long on the fast ports and too short here, and the timer's bound form is not the
window anyway. It now polls for the window actually being renderable, re-queuing
through callSerially rather than sleeping: the paint that makes it renderable
happens on that very thread, so blocking there would stop the condition ever
becoming true.

macNative.multiWindow now defaults to false for the sample as well. That is
measured, not cautious: with multiple scenes enabled, this suite's
OrientationLockScreenshotTest captures its landscape frame and then times out
after 20s trying to restore portrait. Catalyst treats a multiple-scene app's
windows more like Mac windows and honours orientation requests less, so the
regression belongs to the Info.plist key rather than to the window code. This
gives the warning already in IPhoneBuilder a concrete mechanism instead of
folklore.

What the run did confirm: the Info.plist key is emitted correctly,
CN1MacWindows.m compiles clean under Xcode's own flags, the app boots with
multiple scenes enabled and runs all 178 tests without the crash the older
comment described, and MultiWindowApiTest passes on the supported path -- so a
real Catalyst Window is created, registered, resolves getTopLevelContainer() to
itself, reports null from getComponentForm(), reports its monitor and scale, lays
out to its own size rather than the display's, and deregisters on dispose.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Two corrections from further runs on real hardware.

The previous commit blamed multiple scenes for OrientationLockScreenshotTest
timing out while restoring portrait. That was wrong. With the key still enabled
the test passed in the following runs, so it was a slow-machine flake -- the
machine was compiling at the time -- not a consequence of the Info.plist key.
The hint stays off by default anyway, on the honest grounds that it changes
Catalyst windowing process-wide and an application should opt into that rather
than have it changed underneath it.

The screenshot harness was also asking the wrong question. It waited for the
window to report itself showing at its requested size, but a window reports the
size it was asked for before the platform has actually produced anything -- on
Catalyst the scene arrives asynchronously -- so both were true within
milliseconds and the capture then failed. Readiness is now "a capture succeeds",
which is exactly the condition the next line depends on and is correct on every
port.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Running the Catalyst suite showed every windowed screenshot emitting a blank
frame: the sizes differed correctly per window, but the content did not, and the
harness reported the captures as duplicates of each other.

The cause is that a window's raster exists from the moment it is shown, so a
capture taken before the first paint cycle returns an empty frame of the right
size rather than failing. The harness had no way to tell the two apart.

Window now records when a paint cycle has completed and exposes hasPaintedOnce(),
and the screenshot harness waits on that as well as on the capture succeeding.
This is useful beyond the tests: any tooling that wants a window's content rather
than its dimensions needs the same distinction.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Built and ran the conformance suite as a Mac Catalyst app on real hardware with
multi-window enabled: 0 failures across all 178 tests, and all 14 windowed
screenshots captured with distinct hashes and no duplicates -- including the
modal case, whose background window is non-blank while a modal is up, which is
the property that proves the event loop keeps servicing it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The extra macNative.multiWindow switch existed only because Mac Catalyst
scenes were unverified. They are verified now -- the whole conformance
suite runs as a Catalyst app with multiple scenes enabled -- so gating it
behind a second opt-in only meant CI never exercised the feature.

UIApplicationSupportsMultipleScenes is a process wide Info.plist key, so
it is still keyed off macNative.enabled rather than set unconditionally:
that key is true for the Mac Catalyst slice only and false for iPhone and
iPad builds, which keeps the iOS output byte for byte identical.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Inspecting the Mac Catalyst captures rather than only their hashes showed
three defects that distinct hashes had hidden.

A Catalyst scene was never asked for the geometry the window was created
with, so the system handed it the main scene's size. The window then laid
out into a raster that did not match the request: several captures came
out at the main display size with the window's content in the corner.
The scene now requests the pending geometry as soon as it connects, and
both that request and setBounds convert Codename One's pixels to UIKit's
points. getBounds reports pixels to match getWidth and getHeight.

The readiness probe accepted a window that had painted and could be
captured, neither of which implies the size settled -- which is how the
mismatch reached a golden in the first place. It now also requires the
window and the captured image to be exactly the requested size, so a
platform that cannot grant it fails loudly instead of baking a wrong
baseline.

A window used its own Window and WindowContentPane UIIDs, which no theme
written before desktop windows existed defines, so it painted nothing and
came up black. A window is a top level surface, so it now takes the Form,
ContentPane and TitleArea styles every theme already has.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Closing one window and opening another failed on Mac Catalyst with "scene
invalidated before create completion": the system does not hand out a
scene session while a previous destruction is still in flight, and the
window that asked was left without one. That is an ordinary sequence, so
a closed window now parks its scene for the next window to adopt rather
than destroying it.

The size query also answered with the size that was requested while the
scene did not exist yet, so a window looked correctly sized during exactly
the interval when nothing was known about it. It now answers zero until
there is something real to measure, and show() keeps the requested size
until a port delivers a real one instead of collapsing the window to
nothing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…ardown

The macOS runner finally ran the windowed suite to completion -- this is the
first mac-native run on the branch that was not cancelled -- so the twelve
Window-* captures it produced are now committed as goldens. Each is exactly the
size its test requested, and they render the real widget set, list, shapes and
text fields rather than blank surfaces.

Two of the fourteen were not produced. WindowEditingTest captured its first size
and then reported the window at 1024x768, Catalyst's default scene size, for both
remaining sizes, so it never became renderable and timed out. The captured image
shows a caret in the first text field: the editor is genuinely active now that
Display.editString reaches the port from a window, and a native editor holds
platform state tied to the window it is in, which pins the Catalyst scene.

WindowHostTest now stops any editor before tearing its window down, so the next
window is created against a released scene. The remaining two goldens follow once
a run produces them; committing twelve now turns twelve missing_expected
comparisons into real ones rather than leaving the whole set unguarded.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Merged origin/master: the branch was ten commits behind, and the copyright gate
checks the PR's merge result, so a header-less test file added on master was
failing here. Added the header. The merge was clean.

Preserve the requested Catalyst window origin. The creation bridge carries x and
y but adoption hardcoded (0,0), so a window positioned before its first show()
-- a restored layout, or an explicit setWindowLocation -- opened somewhere else.
The origin is now recorded on the slot and used, with no position asked for
still leaving placement to the platform.

Cancel stale geometry settlers. A settler runs for up to a couple of seconds
after its request, and a disposed window's scene returns to the recycling pool
inside that window: the leftover settler would go on sampling and re-requesting
geometry against the scene now hosting a *different* window, resizing the
replacement. It now checks the slot generation and current scene owner before
each step. This is a consequence of the settler added in the previous commit.

Forward a window's title to its toolbar. Once a toolbar is installed it draws
the title and the label setTitle updated is no longer in the hierarchy, so the
change was invisible; getTitle read that stale label too. Both now go through the
toolbar exactly as Form does, while the native window title still follows either
way, since that is the OS chrome's rather than the toolbar's.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>